Markup languages are used to describe data by including tags that distinguish information about the data from the data itself. A client process (“client”) executing on one node of the network employs network protocols to send a request message in the markup language to a server process (“server”) executing on another node. The server responds to the request by providing a service and often employs the network protocols to return a response message in the markup language to the client. The messages are addressed to the proper process on the proper node based on a system for naming the processes on the network. For example, the Universal Resource Identifier (URI) names the node (domain) where a process executes and a directory where a particular executable file resides on that domain.
Extensible Markup Language (XML) provides a common syntax for expressing structure in data. Structured data refers to data that is tagged for its content, meaning, or use. XML provides an expansion of the tagging that is done in Hypertext Markup Language (HTML) and the related Structured Generalized Markup Language (SGML), which focus on format or presentation. In XML the meaning (semantics) of the data can be provided as well as the presentation format. Many applications employ proprietary implementations of XML to communicate between a server and a client. Simple Object Access Protocol (SOAP) is a proposed implementation of XML for exchanging data objects between two processes or “communicating parties” that are independently developed, as described in Simple Object Access Protocol 1—1.htm on the Web at domain and directory w3.org/TR/SOAP, hereinafter referenced as SOAP1.1.
A SOAP message is an XML document that includes a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body. There is a fairly strong similarity between these SOAP elements and the elements of a letter in a postal service. The SOAP envelope, as with a letter's envelope, serves as the unit of transport. The SOAP body, like a letter's contents, is to be carried without being examined or changed. And the SOAP header, like the outside surface of a letter's envelope, is available for various marks or annotations that can affect transport and delivery without disturbing the contents.
The names and attributes of the standard SOAP message elements are defined by an XML schema stored on domain schemas.xmlsoap.org in directory /soap/envelope. The SOAP envelope is the top level XML element of the schema; it is named “Envelope.” The optional SOAP header is an optional child element of Envelope and is named “Header.” The SOAP body is a mandatory child element of Envelope and is named “Body.” The data objects sent between the communicating parties are included in the SOAP Body.
As an example of the problems inherent in working with applications that employ different proprietary implementations of XML to communicate between a server and a client, assume that a user or application wishes to retrieve data about authors of books. Author data and book title data is provided by Company A over the Internet in client/server database A. Database A consists of clientA and serverA; clientA has a GUI that is used by a person, and issues SOAP-based queries to serverA, which retrieves data from the database and answers requests for data from clientA. The clientA application on the user's computer communicates with serverA on the Company A computer using Internet protocols. Inside the packets transported over the Internet are SOAP messages for passing data objects that describe books or authors between clientA and serverA. The data objects are included in a SOAP body of the SOAP message. Assume further that Company B also has a client/server Database B that covers information that overlaps in content with Database A. Database B comprises clientB and serverB that interact in a manner similar to that described above for Database A.
Assume next that database A expects queries to specify author data in the following structure:                <author>                    <firstname>“Mark”</firstname>            <lastname>“Day”</lastname>                        </author>        
However, database B expects queries to specify author data as:                <author>                    <name>                            <given>“Mark”</given>                <family>“Day”</family>                                    </name>                        </author>        
The information that is specified basically is the same, but its markup structure is different. So even if the rest of the interfaces of Database A and Database B are compatible, sending an A query to a B server would fail, and vice-versa.
Similarly, assume that book identifying information is specified to Database A in the form:                <book>                    <title>“My fascinating inventions”</title>            <author><firstname>“Mark”</firstname><lastname>“Day”</la stname></author>                        </book>        
However, Database B expects the form:                <book>                    <booktitle>“My fascinating inventions”</booktitle>            <author><name><given>“Mark”</given><family>“Day”</fa mily></name></author>                        </book>        
Both Database A and Database B have the same basic information, arranged slightly differently. However, if clientA presents a query in the format of Database A to serverB, clientA will receive an error message because the format of Database A is incompatible with Database B. A similar result occurs if Database B receives a query that is formatted for A. Nevertheless, it is desirable to enable queries to run against both databases, regardless of which client is being used.
Based on the foregoing, there is a clear need for techniques for enabling existing servers to provide services over a network that match the services of a revised server. There is a specific need for a way to enable a first server, which expects requests for information according to a first format, to process and respond to queries that are presented in a second, incompatible format.